In a 3GPP Long Term Evolution (LTE) network architecture, handover of a User Equipment node (UE) takes place between Evolved NodeBs (eNBs). A eNB where a User Equipment (UE) is currently located is called a Source eNB (S-eNB). A eNB to which the UE is handed over is called a Target eNB (T-eNB). Handover is a process of handing over the UE from a cell controlled by the S-eNB to a cell controlled by the T-eNB.
FIG. 1 illustrates operations and sequences of messages performed by components of a telecommunications system for handover. Referring to FIG. 1, as a user equipment node (UE) moves into the coverage area of a cell in the T-eNB, it sends a Measurement Report. The Measurement Report triggers a sequence of handover related events by the T-eNB, the S-eNB, and the core network and eventually further involves the UE for handover.
In order to transmit a measurement report over an uplink shared (UL-SCH) channel, the UE must have Physical Uplink Shared Channel (PUSCH) resources. For that purpose the UE reports its buffer status by a buffer status report (BSR). The UE begins by first sending a Scheduling Request.
FIG. 2 illustrates operations and messaging between a UE and S-eNB of a radio access network for sending measurement reports in preparation for handover, and illustrates when a drx-InactivityTimer is started and restarted. The sequence of events in FIG. 2 includes the UE sending a dedicated scheduling request (D-SR) on a Physical Uplink Control Channel (PUCCH). The UE then remains discontinuous reception (DRX) Active, i.e. continuously receiving, while the SR is pending, i.e. until the UE receives a grant on PUSCH or, whichever occurs first, until the UE exhausts a maximum number of attempts (not shown). The UE receives the UL grant and starts a drx-InactivityTimer to further prolong the DRX Active Time. The UE uses the UL grant in accordance with standardized priorities and logical channel prioritization. The BSR describes the size of each buffer in the UE and has highest priority. The radio access network acknowledges the data received on UL-SCH and grants in accordance with the BSR. Once again; the drx-InactivityTimer is started (or restarted). The size of the grant is now large enough for the UE to include the Measurement Report. The sequence ends as orchestrated by the L1/L2 layers of the network, with the UE acknowledging data received and passing the data onwards to its RRC layers. The UE starts (or restarts) the drx-InactivityTimer each time the Physical Downlink Control Channel (PDCCH) indicates a new transmission (DL or UL).
As used herein, the term “Active Time” can be the time related to DRX operation, such as defined in subclause 5.7 of 3GPP TS 36.321, during which the MAC entity monitors the PDCCH. The term “DRX Cycle” can be the periodic repetition of the On Duration followed by a possible period of inactivity. The term “drx-InactivityTimer” can be the number of consecutive PDCCH-subframe(s) after the subframe in which a PDCCH indicates an initial UL, DL or SL user data transmission for this MAC entity.
There is also a case when PUCCH has not been provisioned, where instead the UE must first use the random access procedure to resynchronize by sending a Random Access SR (RA-SR).
FIG. 3 illustrates operations and messaging between a UE and S-eNB of a radio access network for sending measurement reports in preparation for handover, and illustrates starting of a drx-InactivityTimer. The illustrated sequence of events is similar to that of D-SR. In both cases, the Active Time is limited by the drx-InactivityTimer. This timer has been pre-configured by RRC using the current values. FIG. 4 illustrates an example DRX-configuration data structure according to 3GPP TS 36.331 E-UTRA RRC.
A goal of DRX is to conserve battery energy in the UE, including by providing the briefest possible phases of receive Active time when a UE is configured to receive from an eNB. Handover is essential for retainability in a mobile communication network. Handover is usually performed at radio coverage borders and requires as good communication path as possible so that the Handover procedures can be performed quickly and reliably. For this purpose, handover procedures need longer phases of continuous receive Active time than are optimal from a battery saving point of view.
FIG. 5 illustrates two events at times t1 and t2 during the handover phase which can be essential to have good communication between the S-eNB and the UE, and to retain the UE. The timer must be sufficiently long so that the Active time does not end ahead of time t2, which would otherwise result in the UE moving back to DRX sleep which ceases its ability to receive and, thus, cannot be reached by the S-eNB until next a time the UE is awake and ready to receive. FIG. 6 illustrates two events at times t1 and t2 during the handover phase. In the example of FIG. 6, the timer expires before a RRCConnectionReconfiguration message is received at time t2 from the S-eNB resulting in handover failure.
A current approach to attempt to avoid this problem is to use larger timer values (or alternatively to use short repetition cycles), which results in larger handover success rate and better Key Performance Indicator (KPI) retainability but is an unfavorable compromise for DRX with regards to the communication overhead required from the end points providing data services.
Table 1 lists some example compromise DRX schemes. Larger timer values and/or shorter cycles are used for situations where greater robustness for handover is needed.
TABLE 1ServiceLoadTimerCycleMixed MBBLowpsf100sf320Mixed MBBHighpsf200sf320VoLTELowpsf1sf40VoLTEHighpsf5sf20
In Table 1 the services correspond to service specific DRX biased by handover, the timer values are used to configure the drxInactivityTimer, and the cycle values are used to configure the cycle length associated with the longDRX-CycleStartOffset. The term VoLTE refers to voice over LTE, and the term MBB refers to mobile broadband.
There is a continuing problem to address the collision of interests between DRX and handover. The problem is particularly challenging with services that affect VoLTE performance. Service specific DRX increases packet delays and dropped packets, and increases the risk of dropped calls. Moreover, DRX may be tuned in a way that provides insufficient battery lifetime.
Mixed MBB is known to be very bursty with just occasional appearance of small amounts of traffic. Larger timer values, such as 100 ms or 200 ms, defeat many of the goals of DRX because the ever-lasting data tails repeatedly restart the timer before 100 ms or 200 ms has passed.
The negative consequences can be worse and more accentuated for paced services where smaller inactivity timers and larger cycles would otherwise provide much improved battery-savings without sacrificing service QoE. Table 2 lists three examples when service-specific DRX is not biased by handover needs and is better tuned to the services.
TABLE 2ServiceTimerCycleMixed MBBpsf5sf80Paced MBBpsf2sf640VoLTEpsf1sf40
In Table 2 the services correspond to service specific DRX biased. The time values are used to configure the drxInactivityTimer, and the cycle values are used to configure the cycle length associated with the longDRX-CycleStartOffset.
VoLTE provides managed voice which is a core value for the mobile network operator. Competition to VoLTE from Over the Top (OTT) competition, e.g. from Skype or FaceTime, increases the importance of VoLTE performance. Various approaches for increasing VoLTE performance can involve complex retransmission schemes which are unfavorable to both battery economy and handover performance.
It can be harder to find an acceptable compromise for Paced MBB. Paced MBB is important to operators in view of the overwhelming bulk of existing traffic which is handled as Paced MBB. An example of Paced MBB is streaming video such as Youtube or Netflix. Due to user abandonment, it is usually not a good approach to transfer too much content, e.g. a Youtube clip, at once but instead a better approach can be to pace the content. For this purpose efficient DRX schemes are needed which allow a client to quickly fill up a playout buffer and then pace such occasions. Streaming traffic over mobile networks, such as LTE, has been a substantial load on the mobile networks and data volumes are continuing to increase. The current trend suggests that more than half of all traffic over mobile internet will be streaming video.
Table 2 suggests that it may be better to select shorter timers instead of any compromise timers, and to use service-specific cycles instead of the timers that better serve handover. For example, with VoLTE the nature of the voice over IP service is well-defined and allows for matching of the regularity of DRX with that of voice packet arrivals. A shorter cycle can be used because although the UE moves back to DRX sleep quite shortly after t1 it will wake up with shorter regularity. Shorter cycles can be viewed as an opportunity to increase quality of communication, but could negatively affect performance. Shorter cycles, such as 40 ms, increase packet delays and dropped packets. The risk of dropped calls is always higher as a result of discontinued opportunities to communicate.
Operators now occasionally use approaches that manually toggle cell configuration and use the more robust values whenever higher load situations are expected to occur, such as from larger venues and user concentrations. These approaches can be cumbersome to implement. The approach may be difficult to tailor for an individual user's coverage since there is always a tail to the duration required for a procedure. The individual coverage or load situation may grow worse than what is expected in average and might require even more extended Active time for proper communication.
The approaches described in the Background section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in the Background section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in the Background section.